I found that this field is changing the default value from vllm. And it produces the different behavior before stage config refactoring. So I think we don't need to set the default on vllm-omni side. vLLM has the selector method for this field:

https://github.com/vllm-project/vllm/blob/e54894fc85a9861fb38a49701b5844462c3d77e4/vllm/engine/arg_utils.py#L2179-L2260

maybe you can use get_deploy_config_path in tests/helpers/stage_config.py

Does this not support passing arguments from the command line?

Sounds good. But would be better to unify it in a follow-up PR.

For the requirement where fields defined in deploy YAML are selectively overridden,
these fields still need to be retained as a whitelist to preserve the override semantics.

The core issue here is handling default values. A more consistent approach would be to treat
all values as optional (i.e., default to None), and introduce a filtering
step in deploy_create_from_registry(), such as:

explicit_overrides = {k: v for k, v in override_fields.items() if v is not None}

This ensures that only values explicitly provided in the deploy YAML are included in the resulting StageConfig, while missing fields are left unset and handled by downstream default resolution.

With this design, as discussed in #3162:

• For LLM stages, missing fields will fall back to the default values defined in vLLM's EngineArgs.
• For diffusion stages, missing fields will be handled by _create_default_diffusion_stage_cfg,
  which provides safe defaults.

This unifies the override behavior while delegating default resolution to the appropriate
downstream layer.